GramChain Explorer

Explorer Structure

The Explorer (https://gramchain-explorer-test.littlebit.sg/) is the primary public user interface. It can be split into three components:

1. The Parcel Tree acts as a selector device using RFIDs to identify specific parcels. Each tree leaf represents a specific parcel whose details can be displayed in the other components. The tree is for parcels of a single commodity type (e.g. Gold, Silver, Nickel) and is grouped as follows:

• a. Country grouping, also displays the number of pure grams in the country.

• b. Vault subgrouping, the vault within each country along with grams stored at the vault

• c. Parcel, represented by the unique parcel name, grams and a link to parcel details. The Parcel Tree can be filtered, e.g. by brand, status, size, purity or type, to reduce the number of parcels displayed.

2. The Parcel Detail section defaults to the latest parcel event for a given RFID and prominently display the parcel photo and the parcel characteristic as explained under “Hash Data Details”. The parcel photo also has detailed information on when and where the parcel photo was taken and how it was recorded.

3. The Event History section is an expandable list that provides event details on request. Each event has a Date, EventType and Initiator heading to summarize what the event is about. Upon expanding it the Json Data Hash Detail is shown as well blockchain transaction details and links to prove submission of the verifiable hash to the blockchain.

Notable Functionalities & Characteristics

The Explorer is designed to build trust in the system by providing:

1. Transparency comes from the ability to drill down to an individual parcel, then to an event and from there to see each event’s data.

2. Immutability comes from the ability to verify that the event’s data, when hashed, will match the hash submitted to the blockchain. To verify this links to third party blockchain explorers are provided to verify hash broadcast.

3. Fungibility comes from weighting each parcel’s mass by its purity and discarding eventual bullion premiums. Gold coins, for example, have a higher commercial premium over spot than a gold bar. The GramChain ignores such premiums, thereby leading to the standardization towards big gold bars – having the lowest premiums – as higher premium items will either not be deposited or taken out as a delivery.

4. Ease of use comes from having a single, intuitive interface that hides details as collapsible panels allowing for an instinctive drill down functionality that works on any browser of phone.

5. Ease of deployment comes the Angular framework and GramChain APIs used. The combination allows a company specific, white labeled, version of this tool to be deployed by simply coping a bit of code into an HTML page. A deployment can be made in 5 minutes by people with minimal technical skills. This will encourage adoption by third parties.

6. Public Privacy comes from the use of salted hashes to essentially one-way encrypt an arbitrary amount of sensitive data and publicly show the resulting hash. The purpose is to prove what data was submitted without revealing what it is. This works as follows:

• a. Only the data creators and authorized parties possess the readable data (e.g. a PDF document or the login of the person that submitted data). This provides privacy.

• b. However, because only the exact copy of the data (e.g. PDF Document) will re-generate the published Hash the public blockchain hash (or hash of a hash) represents undeniable mathematical prof of what was published. This prevents a party from claiming not to have signed a specific contract or from changing it in any way.

Tree Control Technical Interfaces

Display Modes and Filters

The tree control must be able to handle large (e.g. up to 100,000s) number of parcels while providing an appealing and fast user interface. This scalability is achieved by:

• providing summary groupings
• loading detail data on demand and
• using pagination.

The three controls must also be a flexible tool that accepts multiple filter and layout options as follows:

1. Display Modes: Depending on the chosen display mode data might be categorized differently. This is handled by the API (parameter displaymode in GetTreeStructure), which will change the grouping records as needed. For example, data might be grouped by storage provider for user interested in geographical details or by service provider for usage details. Note that there are three levels of categories as follows:

• a. The top category is always the metal. If there is a single metal only the this should not be shown as a category as it is redundant.
• b. The middle category will always be shown (e.g. Vaults)
• c. The bottom category might or might not be there depending on the dataset.

2. Filter Parameters: These are a small number of filters that can be applied to limit the data returned. These filters should be part of the three control either by using dropdowns or by using image buttons (e.g. a Cache Token logo button might filter for Cache only). In some cases, the controls must be filtered by default. Currently the following Filters are API supported:

• a. EntityID
• b. MetalCode
• c. LockStatusCode
• d. StorageProviderID
• e. ServiceProviderid
• f. CountryCode (might not be offered in UI)
• g. BrandCode (might not be offered in UI)
• h. MeasuredRawGramFrom – measuredRawGramTo (might not be offered in UI)

API Interface

GetTreeStructure returns the categories for the tree based on display mode and optional filters. Categories and headers should be displayed as returned by the API and can range between two to three categories (depending on whether hide property is true or false). There should be three columns for each category:

1. Field “GroupName” and “ParcelNr” is to be displayed as the group header (e.g. Gold, (34) ). Language specific field header should be taken from “GroupHeader” from parent category

2. Field “PureGrams is to be displayed as the next column (e.g. 45,332 g). Language specific field header should be taken from “GramHeader” from parent category

3. Field “Valuation” and “Currency” is to be displayed as the next column (632,324 USD). Language specific field header should be taken from “ValuationHeader” from parent category.

GetTreeLeafs returns the list of parcels that are part of a given category. The API has many filtering variables that match the Leaf category variables so that results can be tailored to the category / filters requested.
The data being returned is minimal as large amounts of records might be returned. To limit data retrievals a viewpagesize parameter defines how many entries can be seen at once (a page) and the viewpagenr specifies what data page is to be shown.

Other: Multilanguage support.